Firmware update system and update image generation/distribution server apparatus

ABSTRACT

There is provided a high-speed firmware update method which reduces the burden on a firmware developer. A server is installed which is provided with a function of receiving an image of new-version firmware (a new firmware image), comparing it with an image of old-version firmware (an old firmware image), taking out only updated files, and creating a procedure for updating the old firmware image to the new firmware image and an update image configured by update data.

TECHNICAL FIELD

The present invention relates to a firmware update system and an updateimage generation/distribution server apparatus.

BACKGROUND ART

There has been commonly performed a method in which, when any fault isfound in software after an integrated apparatus is released, the problemis resolved by rewriting conventional firmware with firmware for whichthe fault has been cleared. Examples of documents about such firmwareupdate include, for example, Patent Document 1 and Patent Document 2below. Here, the firmware is assumed to refer to all data that is storedin a nonvolatile storage area of an integrated apparatus in advance.

Patent Document 1 describes a firmware update method in which allfirmware is replaced. Non-Patent Document 1 discloses a software updateprogram, which is often used in Linux, and which manages software inpackages and distributes an updated software package.

-   Patent Document 1: JP Patent Publication (Kokai) No. 11-110218-   Non-Patent Document 1: Yum: Yellow dog Updater, Modified:    http://linux.duke.edu/projects/yum/

DISCLOSURE OF THE INVENTION Problems to be Solved by the Invention

However, in the method as shown in Patent Document 1, much time isrequired for replacement of firmware because all the firmware isreplaced. In the method as in Non-Patent Document 1, though all firmwareis not replaced, it is troublesome for a firmware developer to managesoftware in packages.

The present invention has been made in view of the above situation andrealizes such firmware replacement that the time required for replacingfirmware is short, and the burden on a firmware developer is not heavy.

Means for Solving the Problems

In order to solve the above problems, a server is installed which isprovided with a function of receiving an image of new-version firmware(a new firmware image), comparing it with an image of old-versionfirmware (an old firmware image), taking out only updated files, andcreating a procedure for updating the old firmware image to the newfirmware image and an update image configured by update data. There isprovided a section which caches only such update images that arefrequently accessed in order to reduce the number of update imagesrequired by the above function. An integrated apparatus is provided witha function of version-upgrading an old firmware image on the apparatusto a new firmware image in accordance with an update procedure in anupdate image. It may be required to reactivate a service after an oldfirmware image is updated to a new firmware image. There is prepared aDB (a reactivation DB) for showing which file update requires whichservice reactivation so that a service reactivation instruction can beinserted into an update procedure in an update image. Furthermore, thereis also provided a section for automating creation of the reactivationDB to reduce the burden on a firmware developer.

That is, the firmware update system according to the present inventionis a firmware update system which updates the image of firmwareincluding software for an apparatus and the configuration data thereof,the system comprising an apparatus which operates on the firmware, andan update image generation/distribution server which generates an updateimage for updating the firmware and transmits the update image to theapparatus. Here, the update image generation/distribution servercomprises an update image generation section which generates an updateimage which is data required for updating a firmware image of theversion being used by the apparatus (a first firmware image) to afirmware image of a new version (a second firmware image), and a datacommunication section which transmits the update image to the apparatus;and the apparatus updates the old-version firmware image on the basis ofthe update image.

The update image generation/distribution server further comprises anupdate image storage section which stores update images each of which isfor two consecutive versions, which are update images each of which isfor two consecutive versions between the oldest-version firmware imageand the newest-version firmware image; and the update image generationsection acquires data required for updating the first firmware image tothe second firmware image, from the update image storage section togenerate the update image. If an update image for two consecutiveversions directly corresponding to update from the first firmware imageto the second firmware image exists in the update image storage section,the update image generation section sets the update image for the twoconsecutive versions as the update image. On the other hand, if theupdate image for the two consecutive versions directly corresponding toupdate from the first firmware image to the second firmware image doesnot exist in the update image storage section, the update imagegeneration section generates the update image by acquiring and mergingall of update images each of which is for two consecutive versions andwhich are required for updating the first firmware image to the secondfirmware image.

The update image generation/distribution server further comprises anupdate image cache section which stores a predetermined number of updateimages with high use frequency. In this case, when having generated thenewest update image, the update image generation section replaces thelowest update image in the update image cache section with the newestupdate image.

The update image generation/distribution server further comprises areactivation instruction DB which stores information indicating whichfile update requires which service reactivation; and the update imagegeneration section refers to the reactivation instruction DB to insert aservice reactivation instruction into the update image to betransmitted. Furthermore, the reactivation instruction DB storesinformation indicating necessity of service reactivation in associationwith a library used by the file; and the update image generation sectionfurther inserts an instruction to reactivate a service corresponding tothe library, into the update image to be transmitted.

Further features of the present invention will be apparent from BestMode for Carrying Out the Invention below and accompanying drawings.

ADVANTAGES OF THE INVENTION

According to the present invention, it is possible to realize suchfirmware replacement that the time required for replacing firmware isshortened and the burden on a firmware developer is reduced.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a diagram showing the whole schematic configuration of afirmware update system according to an embodiment of the presentinvention.

FIG. 2 is a diagram showing the internal data configuration of an HDD ofan update image generation/distribution server.

FIG. 3 is a diagram showing the internal data configuration of a memoryof an apparatus.

FIG. 4 is a diagram showing a configuration example of a firmware image.

FIG. 5 is a diagram showing a configuration example of an update image.

FIG. 6 is a diagram showing a configuration example of a reactivationinstruction DB.

FIG. 7 is a diagram showing a configuration example of an update imagecache.

FIG. 8 is a diagram showing a configuration example of servicename/filename correspondence data.

FIG. 9 is a flowchart for describing a processing operation of an updatecreation function.

FIG. 10 is a flowchart for describing a processing operation of areactivation instruction creation function.

FIG. 11 is a flowchart for describing a processing operation of anupdate distribution function.

FIG. 12 is a flowchart for describing a processing operation of anupdate application program.

BEST MODE FOR CARRYING OUT THE INVENTION

An embodiment of the present invention will be described below withreference to accompanying drawings. However, it should be noted thatthis embodiment is only an example for realizing the present inventionand does not limit the technical scope of the present invention.Components common to the figures are given the same reference numerals.

An embodiment of the present invention will be described below withreference to the drawings.

<Configuration of Firmware Update System>

FIG. 1 is a diagram showing the schematic configuration of a firmwareupdate system according to the embodiment of the present invention. Asshown in FIG. 1, a developer 110 develops software for an apparatus 160and integrates the developed software and a configuration file into afirmware image 120. The firmware image 120 is obtained by archiving thesoftware developed by the developer 110 and the configuration file asone file (see FIG. 4 for its detailed configuration). Then, when it isnecessary to update the software for the apparatus 160, the developer110 transmits the firmware image 120 to an update creation/distributionserver 130 using his own computer (not shown).

The update creation/distribution server 130 is provided with hardware asa computer provided with a network function. That is, the updatecreation/distribution server 130 is provided with a CPU 131 whichexecutes various control processes, a RAM 132, a network interface 133,and an HDD 134 which stores various data, parameters, programs and thelike.

Old-version firmware images 135 are stored in the HDD 134. The updatecreation/distribution server 130 (CPU 131) compares the new firmwareimage 120 developed by the developer with the old-version firmwareimages 135, takes out only parts that have been updated, creates anupdate image 140, and transmits the update image 140 to the apparatus160 via a network 150. The detailed configuration of the update image140 is as shown in FIG. 2, and it will be described later.

The apparatus 160 is provided with hardware as a computer provided witha network function. Examples of this apparatus 160 include an Internetappliance (TV), a broadband router and the like. The minimum componentsto be provided for the apparatus 160 are a CPU 161, a RAM 162, a networkinterface 163 and a flash memory 164. When the firmware is updated, theapparatus 160 transmits a software update request to the updatecreation/distribution server 130, receives an update image 160, andupdates the firmware stored in the flash memory 164. Such a pull-typeconfiguration is possible, and a push-type configuration is alsopossible in which an update image is transmitted from the updatecreation/distribution server 130 to each apparatus 160 as appropriate.In the case of the push-type configuration, it is necessary that theaddress of the apparatus 160 is registered in advance.

<Internal Configuration of HDD 134 of Update Creation/DistributionServer>

FIG. 2 is a diagram showing the composition of data and programs storedinside the HDD 134 of the update creation/distribution server 130 inthis embodiment. The HDD 134 includes a firmware image collection 135,an update image collection 220, a reactivation instruction DB 230,update image cache data 240, service name/filename correspondence data250, an update creation function program 260, a reactivation instructioncreation function program 270 and an update distribution functionprogram 280.

The firmware image collection 135 includes old-version firmware images,and two kinds of firmware images, that is, the oldest-version firmwareimage and the newest-version firmware image, among firmware images thedeveloper 110 transmitted in the past, are stored therein. The exampleof image versions 211 shows that firmware images of a version 1 and thenewest version 50 are stored.

In the update image collection 220, update is stored for each ofversions, from the oldest firmware image to the newest firmware image.That is, if the newest version is 50, then there are stored: “an updateimage indicating update from the firmware image version 1 to a firmwareimage version 2 (expressed as update image 1

2), “update image 2

3”, “update image 3

4”, “update image 4

5”, . . . , “update image 49

50”. Cases other than the case of increment by one, such as update image2

5, are basically not stored, except for exceptional cases such as thecase where the image is frequently used. The configuration of the updateimage is such as shown in FIG. 5.

The reactivation instruction DB 230 stores data to be used by the CPU131 to execute the reactivation instruction creation function (program)270. The detailed data configuration is shown in FIG. 6.

In the update image cache data 240, the frequencies of access to updateimages 221 and data of update images (for example, data of the top-tenupdate images with the highest access frequency) are recorded. Thedetailed configuration is as shown in FIG. 7.

The service name/filename correspondence data 250 is informationindicating pairs of a service name and a corresponding executablefilename. The detailed configuration is as shown in FIG. 8.

The update creation function program 260 is a program for creating theupdate image 140. The details of the function will be described laterwith the use of FIG. 9. The reactivation instruction creation functionprogram 270 is a program for creating the reactivation instruction DB230. The details of the function will be described later with the use ofFIG. 10. The update distribution function program 280 is a program fordistributing an update image stored in the update image collection 220in response to a request from the apparatus 160. The details of thefunction will be described later with the use of FIG. 11. These programsare executed by the CPU 131 to realize the functions, respectively.

<Internal Configuration of Flash Memory 164 of Apparatus>

FIG. 3 is a diagram showing the composition of data, programs and thelike stored in the flash memory 164 of the apparatus 160 in thisembodiment. The flash memory 164 stores a firmware image 310 being usedby the apparatus 160, a version number 320, an operating system 330 andan update application program 340.

The firmware image 310 is image data in which software that operates onthe apparatus and a set of configuration files are stored. The versionnumber 320 indicates the version of the firmware image 310.

The operating system 330 is provided with a function for executing thesoftware stored in the firmware image 310. The update applicationprogram 340 is a program which is provided with a function of receivingthe update image 140 from the update creation/distribution server 130and applying the update described in the update image 140 to thefirmware image 310 and which is executed by the CPU 161. The details ofthe process of the function will be described later with the use of FIG.12.

<Configuration of Firmware Image>

FIG. 4 is a diagram showing the configuration of the firmware image 120according to this embodiment. As shown in FIG. 4, the firmware image 120is constituted by a version number 410 and a firmware data body 420.

The version number 410 indicates the version of the firmware image 120.The version number is the version number of the firmware image 120managed by the developer 110. The firmware data body 420 is generated,for example, by archiving a file system structure using tar, which iswidely used in UNIX (registered trademark) operating system.

<Configuration of Update Image>

FIG. 5 is a diagram showing the configuration of the update image 140 inthis embodiment. In the update image 140, reference numeral 510indicates the version number of an image before update. Referencenumeral 520 indicates the version number of an image after update. Forexample, if the version number 510 is “49” and the version number 520 is“50”, it indicates the update is update from a version 49 of thefirmware image to a version 50.

What are indicated by reference numerals 530 to 560 show an updateprocedure. The reference numeral 530 indicates an update operation. Thereference numeral 540 indicates the full path of an operation targetfile. The reference numeral 550 indicates a reactivation instruction inthe case of relevant update being performed. The reference numeral 560indicates file data corresponding to a full path 540. For example, aline 571 indicates an update procedure for “performing rewriting forfilename/usr/sbin/httpd with file data 560 and then reactivating httpservice”.

That is, FIG. 5 shows what processing procedure has been performed toupdate the firmware image of the version number 49 to the firmware imageof the version number 50. For all the pairs of firmware images of twoconsecutive versions, such update images are stored in the HDD 134 ofthe update creation/distribution server 130 as the update imagecollection 220.

<Configuration of Reactivation Instruction DB>

FIG. 6 is a diagram showing the configuration of the reactivationinstruction DB 230 in this embodiment. As shown in FIG. 6, thereactivation instruction DB 230 stores correspondences between filenames610 and reactivation instructions 620. That is, if a file indicated by afilename 610 is updated, reactivation of the service indicated by acorresponding reactivation instruction 620 is required.

The data of the reactivation instruction DB 230 is generated on thebasis of the service name/filename correspondence data 250 (FIG. 8) tobe described later.

<Configuration of Update Image Cache>

FIG. 7 is a diagram showing the configuration of the update image cachedata 240 in this embodiment. The update image cache data is constitutedby an update classification 710, the number of accesses 720 and updateimage data 730.

The update classification 710 indicates a requested update version. Forexample, “49

50” indicates a request for update from the version 49 to the version50. The number of accesses 720 indicates the frequency at which theupdate classification 710 is requested. Reference numeral 730 indicatesupdate image data. The format of the update image data 730 is as shownin FIG. 5. Only such data 730 that the number of accesses 720 is largeis stored in the update image cache data. For example, only the top tenkinds of data 730 are stored.

<Service Name/Filename Correspondence Data>

FIG. 8 is a diagram showing the configuration of the servicename/filename correspondence data 250 in this embodiment. Thiscorrespondence data is prepared, for example, by the apparatusmanufacturer in advance.

The service name/filename correspondence data is constituted by pairs ofa service name 810 and an executable filename 820 of an executable filewhich realizes the service name 810. For example, a line 831 indicatesthat the name of an executable file which realizes an http service is/sbin/httpd. Depending on the system configuration of the apparatus,this can be automatically prepared.

In a lot of Linux systems, an activation script is prepared for eachservice name. For example, /etc/init.d/httpd is an activation script foran httpd service. This activation script is analyzed, and an executablefile included therein is registered with the service name/filenamecorrespondence data 250. For example, when /etc/init.d/httpd isanalyzed, and /sbin/httpd is found to be included, then httpd service isregistered as a service name 810, and /sbin/httpd is registered as afile name 820.

<Update Creation Function>

FIG. 9 is a flowchart for describing the process of the update creationfunction program 260. Data created by the process in FIG. 9 is theupdate image shown in FIG. 5. The subject of the operation of each stepis the CPU 131 unless otherwise specified. That is, the CPU 131 developsthe update creation function program 260 in the RAM 132 and executeseach step in the program.

When receiving a firmware image 120 acquired from the developer 110 viathe network interface 133 (step S910), the CPU 131 compares the firmwareimage just acquired (new version) and a one version older firmwareimage, and extracts the kind of operation, a full path (file path) anddata of the file (step S920). More specifically, a firmware image(referred to as an old firmware image) which is one version older thanthe firmware image (referred to as a new firmware image) received atstep S910 is stored in the firmware image collection 135. For example,if the version 50 is received at step S910, then the version of the oldfirmware image is 49. Then, the CPU 131 embeds the old version number510 and the new version number 520 in the update image (FIG. 5). Forexample, if the version of the firmware image received at step 910 is50, then the old version number 510 is “49”, and the new version number520 is “50”. Next, the CPU 131 compares the file system structures ofthe new firmware image and the old firmware image and takes out anupdate file, a deleted file and an added file. Then, the columns foroperation 530, full path 540 and file data 560 in the update image arefilled (FIG. 5). For example, if the data of /usr/sbin/httpd is updatedin the new firmware image, “update”, “/usr/sbin/httpd”, and the data of/usr/sbin/httpd included in the new firmware image are stored as anoperation 530, a full path 540 and file data 560, respectively.

Next, the CPU 131 deletes the newest-version firmware image in thefirmware image collection 135 and, instead, stores the firmware image120 received at step S910 as the newest version (step S930).

The CPU 131 refers to the reactivation instruction DB 230 to find areactivation instruction 620 corresponding to the full path 540, andfills the column for reactivation instruction 550 in the update image(step S940). For example, if the full path 540 is “/usr/sbin/httpd”,then the line to which the filename 610 corresponds is a line 631. Sincethe reactivation instruction on the line 631 shows “httpd service”,“httpd service” is recorded as a reactivation instruction 550. If acorresponding reactivation instruction 620 is not found in thereactivation instruction DB 230, then “none” is stored as a reactivationinstruction 550.

Furthermore, the CPU 131 stores the created update image into the updateimage collection 220 (step S950).

<Reactivation Instruction Creation Function>

FIG. 10 is a flowchart for describing the process of the reactivationinstruction creation function 270. Data created by the process in FIG.10 is the data shown in FIG. 6. Again, the subject of the operation ofeach step is the CPU 131 unless otherwise specified. That is, the CPU131 develops the reactivation instruction creation function program 270in the RAM 132 and executes each step in the program. For each line ofthe service name/filename correspondence data 250 (see FIG. 8), theprocessing at steps S1020 to step S1040 is executed.

First, the CPU 131 refers to the service name/filename correspondencedata 250 in FIG. 8 and registers the filename 820 and the service name810 on a corresponding line (831, 832, . . . , or the like) as afilename 610 and a reactivation instruction 620 in the reactivationinstruction DB 230 (step S1020).

Next, the CPU 131 analyzes a shared library used by the filenames 820(step S1030). From the contents (binary) of a filename, a dependencerelationship about which library is used is known. That is, a relatedlibrary is searched at this step. For example, when the filename is/usr/sbin/httpd, the binary of httpd is analyzed to take out the name ofa shared library used. For example, it is assumed that the name of ashare library, libhttpd.so is taken out from the binary of httpd. Thefull path of libhttpd.so is taken out from the search path of the sharedlibrary. If the search path of the shared library is /lib, then the fullpath is /lib/libhttpd.so.

Then, the CPU 131 registers the full path of the library obtained atstep S1030 as a filename 610 in the reactivation instruction DB 230, andregisters the service name registered at step S1020 as a reactivationinstruction 620 (step S1040). Since the library known to be used, atstep S1030 is also involved in the service in association with thefilename, the filename of the library and the service name areregistered so that the library and the service are targeted byreactivation. In the example of step S1030, “/lib/libhttpd.so” isregistered as a filename 610, and “httpd service” is registered as areactivation instruction 620.

<Update Distribution Function>

FIG. 11 is a flowchart for describing the process of the updatedistribution function 280 in this embodiment. Again, the subject of theoperation of each step is the CPU 131 unless otherwise specified. Thatis, the CPU 131 develops the update distribution function program 280 inthe RAM 132 and executes each step in the program. The following stepswill be described on the assumption that the version of the newestfirmware image stored in the firmware image collection 135 is “50”.

First, the CPU 131 receives an update request from the apparatus 160 viathe network interface 133 (step S1110). The update request includes theversion number 320 of a firmware image. Here, description will be madeon a pull type as an example. However, push-type update distribution isalso possible.

Next, the CPU 131 refers to the update classification 710 in the updateimage cache and judges whether the requested update is included in theupdate image cache (step S1120). In the example in FIG. 7, if theversion number received at step S1110 is “48”, then the version of thefirmware image of the apparatus is 48, and update to the newest version50 is included in the update image cache as shown on a line 742.

If it is judged at step S1120 that the requested update is included inthe update image cache, then the CPU 131 distributes a correspondingupdate image 730 in the update image cache to the apparatus 160 (stepS1130). If the version number received at step S1110 is “48”, the updateimage 730 corresponding to the line 742 is distributed. At the sametime, the corresponding number of accesses 720 in the update image cacheis incremented.

On the other hand, if the update image of the requested version is notincluded in the update image cache, at step S1120, then the processproceeds to step S1140. For example, in the example in FIG. 7, theversion number received at step S1110 is “47”, a corresponding updateimage is not included in the update image cache. Then, the CPU 131merges update images included in the update image collection 220 togenerate a necessary update image (step S1140).

The procedure for this merge processing will be described on theassumption that the version number received at step S1110 is “47”. Bymerging “update image 47

48”, “update image 48

49” and “update image 49

50” included in the update image collection 220, “update image 47

50” is created. Specifically, lines including sets of operation 530,full path 540, reactivation instruction 550 and file data 560 of “updateimage 48

49” are added to lines including sets of operation 530, full path 540,reactivation instruction 550 and file data 560 of “update image 47

48”. Similarly, lines including sets of operation 530, full path 540,reactivation instruction 550 and file data 560 of “update image 49

50” are added. Then, the new version number 520 is rewritten to “50”.

Next, the CPU 131 updates the update image cache data (step S1150). Morespecifically, lines with the smallest number of accesses 720 in theupdate image cache data are deleted, and instead, the update imagecreated at step S1140 is added. For example, “47

50” is stored as an update classification 710, “1” is stored as thenumber of accesses 720, and the created update image is stored as updateimage data 730.

Then, the CPU 131 distributes the update image created at step S1140 tothe apparatus 160 via the network interface 133.

<Update Application Process>

FIG. 12 is a flowchart for describing the process of the updateapplication program 340 in the apparatus 160. Here, the subject of theoperation of each step is the CPU 161 unless otherwise specified. Thatis, the CPU 161 develops the update application program 340 in the RAM162 and executes each step in the program.

First, the CPU 161 transmits an update request to the updatecreation/distribution server 130 (step S1210). In the update request,the version number 320 is included.

Then, the CPU 161 receives an update image from the updatecreation/distribution server 130 (step S1220). The update image receivedhere was created by executing the update distribution function 280.

Next, the CPU 161 updates the firmware image 310 using the receivedupdate image (step S1230). For example, if an update image as in FIG. 5is received, the firmware image is updated in accordance with operations530 on the lines 571 to 573. That is, the data of /usr/sbin/httpd isrewritten with the corresponding file data 560, the data of/lib/libfoo.so.1 is deleted, and the data of /usr/sbin/named is createdwith the contents of the corresponding file data 560. The version number320 is updated to the version number shown as the new version number520.

Next, the CPU 161 performs a reactivation process in accordance with areactivation instruction 550 (step S1240). In the example in FIG. 5, thehttpd service is reactivated.

CONCLUSION

Through the above process, update of firmware can be realized. Tosummarize the process of the whole system, the developer 110 transmitsthe newest firmware image 120 to the update creation/distribution server130 first. The apparatus 160 transmits a firmware update request to theupdate creation/distribution server 130 using the update applicationprogram 340. The update creation/distribution server 130 creates anupdate image 140 using the update creation function 260 and transmitsthe update image 140 to the apparatus 160. The apparatus 160 receivesthe update image 140 and updates the firmware to be the newest using theupdate application program 340.

By applying the embodiment of the present invention described above, thetime required for updating the firmware can be shorter than the case ofreplacing all the firmware because only files included in an updateimage 140 are updated when the firmware is updated. Furthermore, sincethe update image 140 is automatically created only by the developer 110sending a firmware image 120 to the update creation/distribution server130, the burden on the developer 110 is reduced.

As an additional advantage, the area for storing update images isreduced. For example, if the newest version of the firmware is 50, only49 kinds of update images, that is, update 1

50, update 2

50, update 3

50, update 4

50, . . . , update 49

50 are required, and it is not required to store all the pairs. Sincethe update 1

50 includes difference corresponding to 49 versions, and update 2

50 includes difference corresponding to 48 versions, a large size isrequired. Instead of storing these, 49 differences, each of whichcorresponds to one version”, are stored as shown as the update images221, and therefore, the area for storing the update images can be small.

The present invention can be realized by a program code of softwarerealizing the functions of the embodiment. In this case, a storagemedium in which the program code is recorded is provided for a system oran apparatus, and a computer (or a CPU or an MPU) of the system or theapparatus reads the program code stored in the recording medium. In thiscase, the program code itself read from the recording medium realizesthe functions of the embodiment described before, and the program codeitself and the recording medium in which the program code is storedconstitute the present invention. As the recording medium for providingsuch a program code, for example, a flexible disk, CD-ROM, DVD-ROM, harddisk, optical disk, magneto-optical disk, CD-R, magnetic tape,nonvolatile memory card, ROM or the like is used.

It is also possible for an OS (operating system) or the like operatingon a computer to perform a part or all of the actual processing on thebasis of instructions of the program code so that the functions of theembodiment described before are realized by the processing. Furthermore,it is also possible for the CPU or the like of a computer to perform,after the program code read from the storage medium is written into thememory on the computer, a part or all of the actual processing on thebasis of instructions of the program code so that the functions of theembodiment described before are realized by the processing.

Furthermore, it is also possible to, by distribution of the program codeof the software realizing the functions of the embodiment via a network,store it into storage means, such as a hard disk and a memory of asystem or an apparatus, or a storage medium, such as a CD-RW and CD-R,and for a computer (or a CPU or an MPU) of the system or the apparatusto read and execute the program code stored in the storage means or thestorage medium when the program code is used.

DESCRIPTION OF SYMBOLS

-   110 developer-   120 firmware image-   130 update creation/distribution server-   140 update image-   150 network-   160 apparatus-   131 CPU-   132 RAM-   133 network interface-   134 HDD-   135 old-version firmware image-   161 CPU-   162 RAM-   163 network interface-   164 flash memory

1. A firmware update system which updates the image of firmwareincluding software for an apparatus and the configuration data thereof,the system comprising: an apparatus which operates on the firmware, andan update image generation/distribution server which generates an updateimage for updating the firmware and transmits the update image to theapparatus; wherein the update image generation/distribution servercomprises an update image generation section which generates an updateimage which is data required for updating a firmware image of theversion being used by the apparatus (a first firmware image) to afirmware image of a new version (a second firmware image), and a datacommunication section which transmits the update image to the apparatus;and the apparatus updates the firmware image of the version being usedon the basis of the update image.
 2. The firmware update systemaccording to claim 1, wherein the update image generation/distributionserver further comprises an update image storage section which storesupdate images each of which is for two consecutive versions, which areupdate images each of which is for two consecutive versions between theoldest-version firmware image and the newest-version firmware image; andthe update image generation section acquires data required for updatingthe first firmware image to the second firmware image, from the updateimage storage section to generate the update image.
 3. The firmwareupdate system according to claim 2, wherein if an update image for twoconsecutive versions directly corresponding to an update from the firstfirmware image to the second firmware image exists in the update imagestorage section, the update image generation section sets the updateimage for the two consecutive versions as the update image; and if theupdate image for the two consecutive versions directly corresponding tothe update from the first firmware image to the second firmware imagedoes not exist in the update image storage section, the update imagegeneration section generates the update image by acquiring and mergingall of update images each of which is for two consecutive versions andwhich are required for updating the first firmware image to the secondfirmware image.
 4. The firmware update system according to claim 3,wherein the update image generation/distribution server furthercomprises an update image cache section which stores a predeterminednumber of update images with high use frequency.
 5. The firmware updatesystem according to claim 1, wherein the update imagegeneration/distribution server further comprises a reactivationinstruction DB which stores information indicating which file updaterequires which service reactivation; and the update image generationsection refers to the reactivation instruction DB to insert a servicereactivation instruction into the update image to be transmitted.
 6. Thefirmware update system according to claim 5, wherein the reactivationinstruction DB stores information indicating necessity of servicereactivation in association with a library used by the file; and theupdate image generation section further inserts an instruction toreactivate a service corresponding to the library, into the update imageto be transmitted.
 7. An update image generation/distribution serverapparatus which operates in a firmware update system which updates theimage of firmware including software for an apparatus and theconfiguration data thereof, generates an update image for updating thefirmware, and transmits the update image to the apparatus, the serverapparatus comprising: an update image generation section which generatesan update image which is data required for updating a firmware image ofthe version being used by the apparatus (a first firmware image) to afirmware image of a new version (a second firmware image); and a datacommunication section which transmits the update image to the apparatususing the firmware.
 8. The update image generation/distribution serverapparatus according to claim 7, comprising: an update image storagesection which stores update images each of which is for two consecutiveversions, which are update images each of which is for two consecutiveversions between the oldest-version firmware image and thenewest-version firmware image; wherein the update image generationsection acquires data required for updating the first firmware image tothe second firmware image, from the update image storage section togenerate the update image.
 9. The update image generation/distributionserver apparatus according to claim 8, wherein if an update image fortwo consecutive versions directly corresponding to an update from thefirst firmware image to the second firmware image exists in the updateimage storage section, the update image generation section sets theupdate image for the two consecutive versions as the update image; andif the update image for the two consecutive versions directlycorresponding to the update from the first firmware image to the secondfirmware image does not exist in the update image storage section, theupdate image generation section generates the update image by acquiringand merging all of update images each of which is for two consecutiveversions and which are required for updating the first firmware image tothe second firmware image.
 10. The update image generation/distributionserver apparatus according to claim 9, further comprising an updateimage cache section which stores a predetermined number of update imageswith high use frequency.
 11. The update image generation/distributionserver apparatus according to claim 7, further comprising a reactivationinstruction DB which stores information indicating which file updaterequires which service reactivation; wherein the update image generationsection refers to the reactivation instruction DB to insert a servicereactivation instruction into the update image to be transmitted. 12.The update image generation/distribution server apparatus according toclaim 11, wherein the reactivation instruction DB stores informationindicating necessity of service reactivation in association with alibrary used by the file; and the update image generation sectionfurther inserts an instruction to reactivate a service corresponding tothe library, into the update image to be transmitted.